Conversation
newpavlov
force-pushed
the
keccak/closure
branch
from
3546f83 to
57c6fba
Compare
|
I am not sure how to deal with the SIMD "backend". It adds support for operating over One potential option is to introduce @aewag |
newpavlov
force-pushed
the
keccak/closure
branch
2 times, most recently
from
0945c16 to
fb99f23
Compare
|
@newpavlov as a general rule SIMD backends are going to keep the state in SIMD registers between rounds, with an initial load step and at the end of a given number of rounds a store step which splits them back out into an array of states |
newpavlov
force-pushed
the
keccak/closure
branch
from
d6048bf to
3a0b85e
Compare
|
@tarcieri |
| /// Trait used to define a closure which operates over Keccak backends. | ||
| pub trait BackendClosure { | ||
| /// Execute closure with the provided backend. | ||
| fn call_once<B: Backend>(self); |
There was a problem hiding this comment.
We could modify it to return a result (i.e. fn call_once<B: Backend>(self) -> Self::Output) and modify the Keccak methods accordingly, but I am not sure it's worth the trouble.
|
To me it would make more sense if the different state sizes and their backends were modeled as separate types, rather than listing them all out in a single trait/type. That's how we do things everywhere else that some algorithm/construction is implemented for different sizes. I'm not sure it even makes sense to support this for any state size other than |
We could do it, but it would result in a fair amount of somewhat annoying boilerplate. On the other hand, it would resolve the issue with the software fallback, since backends will be selected independently for each function.
I am not aware about potential parallel uses for those, so maybe not. I was trying to future-proof the API and adopting the portable SIMD implementation for it looks simple enough. I guess we could start with parallel support only for b=1600 and add other functions later if needed. |
| #[inline] | ||
| fn as_mut(&mut self) -> &mut [u64; PLEN] { | ||
| &mut self.state | ||
| pub fn with_f800(&self, f: impl FnOnce(Fn800)) { |
There was a problem hiding this comment.
These methods are kept for consistency with the f/p1600 methods and to future-proof the API.
tarcieri
left a comment
tarcieri
left a comment
There was a problem hiding this comment.
Not sure what's up with the commented out sections but having something in place for this seems good and I don't want to delay a release too much. If we get the API nailed down I can add e.g. SSSE3 and/or AVX2 later.
I'm also fine with keeping things infallible.
It's mostly the portable SIMD stuff. I plan to introduce |
newpavlov
force-pushed
the
keccak/closure
branch
from
7b487ea to
85cf139
Compare
newpavlov
force-pushed
the
keccak/closure
branch
from
0e08c2c to
829338e
Compare
|
Note the backend selection and |
| pub struct Keccak { | ||
| #[cfg(target_arch = "aarch64")] | ||
| has_intrinsics: armv8_sha3_intrinsics::InitToken, | ||
| armv8_sha3: armv8_sha3_intrinsics::InitToken, |
There was a problem hiding this comment.
Note that the token will be always initialized even when backend is pinned using keccak_backend. We could fix it, but it results in a pretty annoying cfgs.
2 participants
The new API provides a better way for exposing support for parallel processing in implemented backends and resolves the issue with branching on each application of a Keccak permutation.
TODO: Update changelog.